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(57) ABSTRACT 

In an Internet based personalized radio, where a user has a 
pre-selected list of songs to be played in a particular order, 
the invention provides an apparatus and method allowing the 
user to skip one or more songs without having an unintended 
delay between skips. This is accomplished by pre-buffering 
the first ten seconds of each of the next several songs on the 
list so that, should the user choose to skip to any of the next 
several songs, the pre-buffered ten seconds of the target song 
is already available to be played. The apparatus starts to play 
the pre-buffered port of the target song and starts to down- 
load the rest of it at the same time. Because the initial 
buffering time for the rest of the target song is less than ten 
seconds, the target song is played smoothly. 
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Assume there are P songs in the play list. Whenever a 
song starts to play, download and pre-buffer the first X 

seconds of each of the next N (N^P) songs 
consecutively. This pre-buffering process is dynamically 
updated. Preferably, X=10; N=5 
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Once a song (in a play list of P songs) starts to play, 
download and pre-cache the first X seconds of each of 
the N subsequent songs consecutively (N £ P). If one has 
already been pre-cached, skip to next one. Always keep 
N pre-cached ones in the buffer (e.g.: X = 10; N = 5 ) 
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APPARATUS AND METHOD FOR SKIPPING 
SONGS WITHOUT DELAY 

BACKGROUND OF THE INVENTION 
[0001] 1. Technical Field 

[0002] This invention generally relates to Internet based 
personalized radio/music technology. More particularly, the 
invention relates to an apparatus and method allowing a user 
to skip one or more songs in a pre- selected play list without 
having an unintended delay between skips. 

[0003] 2. Description of the Related Art 

[0004] Internet based personalized radio services, such as 
Radio@AOL and iSelect, provide users a high flexibility to 
choose programs and make their own play list using a 
graphical user interface which is part of the client applica- 
tion of the service. The client application sends a user's 
request to the server and the server responds to the user's 
request by returning the requested in compressed data. The 
client application along with the user's browser executes a 
decompression algorithm to decompress the compressed 
data in real time and sequentially plays the data as it is 
transferred from the server to the user's computer over the 
Internet. Using streaming technologies, the user's computer 
does not need to download the entire file first and then play 
it. Rather, after downloading a minimal section of data into 
a buffer, the user's computer reads from the buffer and plays 
the song or music represented by the data. The data already 
read by the computer is deleted from the buffer so as to ease 
the RAM requirements and maintain a balance between the 
write-in and the read-out data flows. 

[0005] When the user's computer plays a play list or a 
preset, which is either created by the user or by the service 
provider, the server sends and the user's computer receives 
the data over the Internet in a programmed sequence so that 
there is no unintended delay between any two programs in 
the list. If the user does not interrupt, the computer plays the 
songs in the list one by one in an organized consecutive 
manner. However, when the user switches from one list or 
preset to another, the users actually interrupts the natural 
flow of the play list or the preset. In these circumstances, 
because the computer has to request that the server start to 
send the data for the target list or preset, several seconds of 
loading time is needed. Likewise, when the user wants to be 
actively be involved in the sequence of the play list or preset 
by skipping one or more songs, as it is illustrated in FIG. 
2C, the natural flow of the pre-determined play list or preset 
is interrupted by the loading transition. This type of unin- 
tended delay between skips has been a major factor affecting 
users experience using personalized radio service. 

[0006] Therefore, there is a need in the art to provide a 
solution to overcome the unintended delay or pause problem 
caused by a user's skipping from one song to the other while 
a pre-determined list of selections is playing in a pro- 
grammed sequence. 

SUMMARY OF THE INVENTION 

[0007] In an Internet based personalized radio, where a 
user has a pre-selected list of songs to be played in a 
particular order, the invention provides an apparatus and 
method allowing the user to skip one or more songs without 
having a delay between skips. This is accomplished by 



downloading and pre-caching, i.e. pre-buffering the first 
small portion of each of the next several songs on the play 
list so that, should the user choose to skip to any of the next 
several songs, the pre-buffered small portion of the target 
song is already available to be played and therefore there is 
no unintended delay between two songs. The apparatus 
starts to play the pre-buffered small portion of the target 
song and starts to download the rest of the target song at the 
same time. Because the system is so configured that the time 
for playing the pre-buffered small portion is longer than the 
initial buffering time for the rest of the target song, the entire 
target song is played smoothly. In other words, there is no 
unintended delay between the first small portion and the rest 
portion either. 

[0008] In the preferred embodiment of the invention, the 
first small portion is approximately the first ten seconds of 
the song. This solution is advantageous because ten seconds 
of pre-buffering complies with various royalty requirements 
such that if the user skips before the ten seconds pre-buffered 
portion is played, a royalty is not accessed for listening to the 
song. In addition, avoiding of downloading the entire next 
song conserves bandwidth and memory. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] FIG. 1A is a schematic diagram illustrating a 
system in which a user uses a graphical interface running on 
a local computer to access a radio service provided by a 
remote server over the Internet; 

[0010] FIG. IB is a block diagram further illustrating the 
local environment in which the preferred embodiment of this 
invention operates; 

[0011] FIG. 2A is a schematic diagram illustrating a 
natural flow of the user's play list, which is a sequence of 
songs pre-selected by the user via the graphical user inter- 
face supported by the client application in FIG. 1 A and FIG. 
IB; 

[0012] FIG. 2B is a schematic diagram illustrating how a 
buffer works; 

[0013] FIG. 2C is a schematic diagram illustrating how 
the natural flow of the user's play list is interrupted by skips; 

[0014] FIG. 3A is a schematic diagram illustrating a 
pre-buffering solution according to the preferred embodi- 
ment of this invention; 

[0015] FIG. 3B is a flow chart illustrating a process 
according to the pre-buffering solution according to FIG. 
3A; 

[0016] FIG. 3C is a flow chart further illustrating a major 
loop of FIG. 3B; and 

[0017] FIG. 3D is a flow chart further illustrating another 
major loop of FIG. 3B; and 

[0018] FIG. 4 is a schematic diagram illustrating the data 
capacity of a communications channel being shared by the 
streaming for playing a song and the streaming for down- 
loading. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0019] Referring to the drawings, in particular to FIG. 1A 
and FIG. IB, which, in combination, illustrates an environ- 
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ment where this invention embodies. FIG. 1A is a schematic 
diagram illustrating a system in which a user uses a graphi- 
cal interface 110 running on a local computer 120 to access 
a radio service provided by a remote server 130 over the 
Internet 140. The local computer is powerful enough to 
execute in real time a decompression algorithm required for 
streaming. 

[0020] FIG. IB is a block diagram further illustrating the 
local environment in which the preferred embodiment of this 
invention operates. The local environment includes a com- 
puter platform 121 which includes a hardware unit 122 and 
an operating system 123. The hardware unit 122 includes at 
least one central processing unit (CPU) 124, a read only 
random access memory (usually called ROM) 125 for 
storing application programs, a write/read random access 
memory (usually called RAM) 126 available for the appli- 
cation programs' operations, and an input/output (IO) inter- 
face 127. Various peripheral components are connected to 
the computer platform 121, such as a data storage device 
128, an audio system 129 such as an MP3 player, and an 
Internet connection interface such as an Ethernet 107. The 
user uses a web browser 108 to go online. An Internet radio 
client application 109, which supports the graphical user 
interface 110, runs on the computer platform 121. The client 
application 109, along with an advanced clip loader which 
is also called piledriver, can be deployed as a plug-in to the 
web browser 108 such as the Netscape Navigator. Those 
skilled in the art will readily understand that the invention 
may be implemented within other systems without funda- 
mental changes. 

[0021] Using clip based data streaming technologies, the 
user's local computer 120 can play audio or video program 
in real time as it is being downloaded over the Internet as 
opposed to pre-storing the entire program in a local file. The 
Internet radio client application 109 coupled to the web 
browser 108 decompresses and plays the data as it is being 
transferred to the local computer 120 over the Internet. The 
piledriver is responsible for delivering, for example, an 
Ultra vox formatted stream to the client application in a 
seamless fashion, in addition to raw data. Streaming audio or 
video avoids the unintended delay entailed in downloading 
an entire file and then playing it with a helper application. 
For the clip based streaming to work, the client side receiv- 
ing the data must be able to collect the data and send it as 
a steady stream to the program that is processing the data 
and converting it to sound or pictures. This means that if the 
data does not come more quickly enough, the presentation of 
the data will not be smooth. If the streaming client receives 
the data more quickly than required, it needs to save the 
excess data in a buffer, which is an area of memory in the 
write/read random access memory (RAM). Even when the 
write speed and the read speed are exactly same, to maintain 
a smooth data flow, a minimum amount of data in the buffer 
is necessary. 

[0022] From a high level view, the piledriver receives a 
play list from an audio or video client application. It 
analyzes the play list and locally caches the first small 
portion (e.g. first ten seconds) for clip in the play list. The 
client can then connect to the piledriver data pump and 
retrieve the data stream using the HTTP or Ultravox 2.0 
Protocols. The major functions of the piledriver include: (1) 
managing the retrieval and caching the pre-butter for items 
in the play list; (2) managing the content in memory; (3) 



providing content to audio or video clients using raw data or 
the Ultravox 2.0 protocol from either a local cache or 
directly from a content- store; and (4) providing a stream of 
data to the audio or video client mimicking local disk 
functionality. 

[0023] The piledriver takes a play list and attempts to 
present an uninterrupted stream of audio or video output to 
the client application. One of the primary features of the 
client application is that it allows the listener to abort a 
current song being played and request the start of the next 
clip in the play list. 

[0024] In order to minimize the amount of time taken for 
skipping, the piledriver performs two operations in parallel. 
First, it requests the first URL in the play list from the 
UltraMODS/HTTP server. Once the pre-buffer data arrives, 
it waits for the audio or video client to start playing the clip, 
and also continues downloading the pre-buffer segments for 
each of the next clips in the play list, in order. 

[0025] There are two reasons to request the pre-buffers in 
advance. First, it reduces the delay involved in requesting 
the clip and then obtaining the pre-buffer before being able 
to play the audio or video. Second, it causes UltraMODS/ 
HTTP to obtain the media file from the content- store if it 
does not have it already, hopefully in advance of the new by 
the client. 

[0026] The functional components for the piledriver 
include a pre-buffer cache engine and a clip/stream retrial 
application program interface (API). The pre-buffer cache 
engine is responsible for caching clips in advance of play- 
time. The clip/retrial API contacts the Apache/UltraMODS/ 
Cache engine for content. For illustration purpose, given 
below is an exemplary list of API calls and their functions: 

pdlnit 

[0027] PILEDRIVERTYPE *pdlnit(int cacheahead, int 
initringsize) 

[0028] This is the first function called to initialize the 
piledriver. The number of clips to cache in advance and the 
size of the pre-buffer cache can be specified. 

pdAddltem 

[0029] PDF ILEH ANDLE pdAddItem(PILEDRIVER- 
TYPE ^piledriver, char *url, unsigned long start, unsigned 
long end) 

[0030] Call to add a URL to the cache-ahead playlist. It 
can be configured to add the entire play list, or just enough 
to keep the cache-ahead system busy. 

pdOpen 

[0031] PDFILEHANDLE 

pdOpen(PILEDRIVERTYPE*piledriver, PDFILE- 
HANDLE handle) 

[0032] Call to open PFFILEHANDLE after the item has 
been added to the cache engine with pdAddltem. If the file 
is cached it returns the size of the pre-buffer, 0 if no 
pre-buffer, or -1 if there was an error related to the files 
availability. 

pdReadRaw 

[0033] int pdReadRaw(PILEDRIVERTYPE *piledriver, 
char *buffer, unsigned int toread, PDFILEHANDLE handle) 
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[0034] Call to an opened PFFILEHANDLE to retrieve 
data. The size of the data is returned, 0 if none, -1 if EOF 
(End of File) has been reached or the connection was 
broken. 

pdReadCooked 

[0035] int pdReadCooked(PILEDRIVERTYPE 
*piledriver, char *buffer, int toread, unsigned short *msg- 
type, PDFILEHANDLE handle) 

[0036] Call to an opened PFFILEHANDLE to retrieve 
Ultravox messages. The size of the data is returned, and 
msgtype contains the clad and type of the Ultravox message. 
0 is returned if no message is available, and -1 if EOF has 
been reached or the connection was broken. 

pdClose 

[0037] int pdClose(PILEDRIVERTYPE *piledriver, 
PDFILEHANDLE handle) 

[0038] Call to close and remove the cache-ahead engine a 
PFFILEHANDLE. Always call this function even if the file 
failed to open. 

pdDelnit 

[0039] int pdDeInit(PILEDRIVERTYPE *piledriver) 

[0040] Call to stop all each-ahead transactions, close and 
remove all open PFFILEHANDLEs and free all used 
memory. 

Error Notification 

[0041] Call to make error notification. In the event of an 
error in any of the API functions, PILEDRIVERTYPE- 
>error and PILEDRIVERTYPE->error-bufTer contain the 
error code and the error string associated with the current 
error condition. Error codes are located in PDRIVER.H 

[0042] FIG. 2 A is a schematic diagram illustrating a 
natural flow of the user's play list, which is a sequence of 
songs pre-selected by the user via the graphical user inter- 
face 110 supported by the client application 109 in FIG. 1A 
and FIG. IB. Upon the user's command to play his play list, 
the client application 109 first checks whether there is a file 
characterized as the first song (S_l) of the play list is 
available in the buffer. If not, then start downloading the data 
from the server 130 over the Internet. After an initial 
buffering time 210, the sequence of songs is played in a 
continuous manner. FIG. 2B is a schematic diagram illus- 
trating a buffer 211 which is an area of memory for tempo- 
rarily storing the data downloaded from the server 130 over 
the Internet. The buffer 211 is used to decouple processes so 
that the reader 213 and writer 212 may operate at different 
speeds or on different sized blocks of data. For smooth 
playing a song or a sequence of songs, the initial buffering 
time 210 is necessary. 

[0043] However, when the user chooses to skip to a next 
song before the current song ends, the natural flow is 
interrupted because it takes time to send the skip command 
to the server which starts to transmit the data for the next 
song, and thus a new period of buffering time is required 
before the next song starts to play. For example, as illus- 
trated in FIG. 2C, after the initial buffering time 210, the 
first song S_l starts playing at the time t x Before the first 
song S_l ends, the user decides to skip to the second S_2 at 
the time t a . When the application receives the command to 



skip to the second song S_2, the reader 213 stops reading 
and the writer 212 stops writing the rest data for S_l, and at 
the same time the application notifies the server to stop 
transmission of the data for S_l. Then, the application 
checks whether there is a file characterized as S_2 in the 
buffer 211. Because S_2 is not downloaded yet, the appli- 
cation sends the server a request to transmit the second song 
S_2. Thus, a buffering time 220 (from t a to t b ) is needed 
before S_2 starts. After the buffering time 220 (from t a to t b ), 
the reader 213 starts to read S_2 at the time t b . Similarly, 
when the user decides to skip to the third song S_3 before 
the S_2 ends, a buffering time 230 (from t c to t d ) is needed 
before S_3 starts at time t d . Because each buffering time is 
about several seconds, the music flow 250 is interrupted and 
the user experience is affected. 

[0044] FIG. 3A and FIG. 3B are schematic flow diagrams 
illustrating a solution to overcome the problems as illus- 
trated in FIG. 2C. The solution includes the following steps 
to be executed by the computer: 

[0045] Step 301: Start downloading the second song S_2 
immediately after the initial buffering time 210 is over at the 
time t ± This step is called pre-buffering or pre-caching. The 
application is configured to download only the first few 
seconds of S_2. In the preferred embodiment, the applica- 
tion is configured to download the first ten seconds. After 
download the first ten seconds of the second song, start 
downloading the first ten seconds of the third song. The 
similar pre-buffering step goes so on and so forth. In the 
preferred embodiment, the application is configured to 
download and pre-buffer the first ten seconds of five songs 
subsequent to the current song which is being played. The 
total time required for pre-buffering five songs is about one 
minute. Usually a user would be able to decide whether or 
not to continue the song after listening to it for one minute. 
Therefore, although the application can be otherwise con- 
figured, pre-buffering five songs would be good enough for 
most of circumstances. 

[0046] Step 302: Assuming the user decides to skip to a 
target song (for example S_5), the application first check 
whether there is a file characterized as the target song. 

[0047] Step 303: If S_5 is identified in the buffer and 
because the first ten seconds of S_5 is already there, the 
system can start to read S_5 immediately. This means that 
there is no unintended delay between S_l and S_5 unless the 
networking condition is abnormally bad or the user has 
exhausted the local cache. At the same time, the application 
asks the server to transmit the rest of S_5 to the buffer. 
Because the buffering time for the rest of S_5 is less than ten 
seconds, by the time the reader finishes reading the pre- 
buffered ten seconds of S_5, a sufficient part of the rest of 
S_5 is already there and is ready to be read. Therefore, there 
is no interruption between the first ten seconds of S_5 and 
the rest of S_5. In this way, the user experience is enhanced 
and waiting time is minimized. 

[0048] Step 304: While the song (S_5) is being displayed, 
update Step 301 to keep five songs subsequent to the current 
one being pre-buffered. 

[0049] Step 305: Play next song after S_5 is over. 

[0050] Step 306: Repeat Step 302 if the user wants to skip 
while S_5 is being played. 
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[0051] Steps 301-306 represents the first loop in which the 
user's play list is played without interruption even he 
sometimes decides to skip one or more songs. 

[0052] This invention also helps to bring the song playing 
back into the first loop when an interruption occurs. 

[0053] Step 310: If the check result in Step 302 is no (i.e. 
the target song S_5 is not identified in the buffer), the system 
requests that the server stop transmitting the prior song (S_l 
in the example) and start transmitting the target song. 

[0054] Step 311: Start to download the target song. 
Because the target song is not pre-buffered, an initial buff- 
ering time is required before the target song can be played. 
During initial buffering time, typically 5-6 seconds, the 
system is silent. 

[0055] Step 312: Start to play the target song. This step 
leads to step 305 or step 306, and step 301. Because the 
system always attempts to have five next songs pre-buffered, 
if the target song is one of the pre-buffered, the natural flow 
of the play list will not be interrupted by skipping. 

[0056] When the user skips to the target song, the pre- 
buffered songs which are prior to the target in the play list 
(e.g. S_2-S_4 if the user skipped from S_l to S_5) will be 
deleted from the memory just as they had already been 
played. 

[0057] If the application is configured to keep the skipped 
pre-buffered data for a short period of time, for example for 
10 seconds, the user could, though not very much meaning- 
ful for many people, come back to any of the songs before 
it is deleted from the buffer. 

[0058] FIG. 3C and FIG. D are flow charts further illus- 
trating the various loops according to FIG. 3B. 

[0059] Referring to FIG. 3C, step 330 actually includes 
following two sub -steps: 

[0060] as soon as a song starts to play, download, 
consecutively, a first small portion (e.g. ten seconds) of 
each of a number of songs which are, in the pre- 
determined sequence (i.e. play list), subsequent to the 
song which is currently playing; and 

[0061] pre-cache the downloaded small portions in a 
buffer which is an area of the user's computer memory. 

[0062] In step 33 OA, assuming the user skips to a song 
(called target song) in the play list before the song in playing 
is over, the computer checks whether the target song belongs 
to one of these pre-cached in step 330 by checking whether 
a file characterized as the target song exists in the buffer. If 
yes, go on to step 330B in FIG. 3D. 

[0063] Referring to FIG. 3D, step 330B includes the 
following sub-steps: 

[0064] play the first small portion of the target song; 

[0065] start to download the rest of the target song (by 
identifying a ten seconds mark, for example); and 

[0066] delete any pre-cached song which is prior to the 
target song in the pre -determined sequence. 

[0067] Note that as soon as the pre-cached portion of the 
target song starts playing, step 330 needs to be updated. In 
particular, if one or more songs subsequent to the target song 
are already pre-cached, skip them and download the subse- 
quent ones, executively, to make up the pre-designated 
number (five, for example). 



[0068] In step 337, when the playing of the pre-cached 
portion ends, immediately play the rest of the target song 
which is being downloaded from the server over the Internet. 

[0069] In steps 338-339, if the user does not want to skip 
to another song while the target song is playing, then play 
the next song in the sequence, and at the same time, delete 
any pre-cached song which is prior to this song. As soon as 
this song starts playing, step 330 needs to be updated. 
Because all pre-cached files, which are prior to this song in 
the sequence, have been deleted from the buffer, the user's 
computer must send request to the server to transmit the first 
small portion (e.g. ten seconds) of a designated number of 
songs, one by one. Then, the user's computer downloads and 
pre-caches these files in the buffer. 

[0070] If the user wants to skip to another song before the 
playing of the target song in steps 330B-337, the process 
continues on step 33 OA in FIG. 3C which illustrates another 
loop. 

[0071] No referring to FIG. 3C, in step 300A, the user's 
computer checks whether the new target song is already 
pre-cached by checking whether a file characterized as the 
new target song exists in the buffer. If not, go to step 331 
which includes two sub-steps: 

[0072] send request to the server to stop transmitting of 
the song in playing and to start transmitting the new 
target song; and 

[0073] at the same time, delete the pre-cached portion 
for any song which is prior to the new target song in the 
designated sequence of songs. 

[0074] Then, start to download the new target song in step 
332. Because the new target song is not pre-cached, it takes 
a short period of buffering time (about five seconds) before 
the computer can play the song. This buffering time causes 
the interruption of the natural flow of the user's play list. 
This invention helps minimize the occurrences of the inter- 
ruption. If the user always skips to a pre-cached song, no 
interruption would occur at all unless the networking con- 
dition is abnormally bad or the user has exhausted the local 
cache. 

[0075] In step 333, as soon as the buffer allows, play the 
new target song while it is being downloaded. At the same 
time, update step 300 by deleting outdated pre-cached files 
(i.e. the pre-cached portions of the songs prior to the new 
target song) and pre-buffering the subsequent songs. This 
step is important because it helps the user to return to the 
none-interruption loop. 

[0076] Assuming the user does not to skip again while the 
new target song is playing, go to step 335 which includes the 
sub -steps of: 

[0077] as soon as the playing of the new target song 
ends, play the first small portion of the next song 
subsequent to the new target song; 

[0078] at the same time, download the rest of the "next 
song" (beginning from the ten seconds mark, for 
example); and 

[0079] update step 300, wherein if one or more songs 
subsequent to this "next song" are already pre-cached, 
skip them and download the subsequent ones, execu- 
tively, to make up designated number. 

[0080] Then, in step 336, play the rest of the "next song" 
as soon as the pre-cached portion ends. 
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[0081] If the user wants to skip again, the loop starting at 
step 3 00 A will be repeated. 

[0082] The pre-caching (i.e. the pre -buffering) solution 
described above is possible because the total capacity of the 
communication channel can be shared between several 
independent data streams using some kind of multiplexing, 
in which, each stream's data rate may be limited to a fixed 
fraction of the total capacity. As it is illustrated in FIG. 4, the 
data transfer rate for a regular DSL communications channel 
ranges from 256K to 8 M byte per second (bps), the voice 
conversations and music signals only use 64K bps. There- 
fore, the streaming track for the downloading data for 
pre-buffering can use the rest capacity. 

[0083] The solution described above can also be used in 
Internet based video service and any other services where an 
initial buffering time is needed before the first section of the 
downloaded data can be read. 

[0084] In the preferred embodiment of the invention, the 
first small portion is approximately the first ten seconds of 
the song. This solution is advantageous because ten seconds 
of pre-buffering complies with various royalty requirements 
such that if the user skips before the ten seconds pre-buffered 
portion is played, a royalty is not accessed for listening to the 
song. In addition, avoiding of downloading the entire next 
song conserves bandwidth and memory. 

[0085] In view of the different possible embodiments to 
which the principle of this invention may be applied, it 
should be recognized that the preferred embodiment 
described herein with respect to the drawings is meant to the 
illustrative only and should not be taken as limiting the 
scope of the invention. One skilled in the art will readily 
appreciate that other applications may be substituted for 
those set forth herein without departing from the spirit and 
scope of the present invention. 

[0086] Accordingly, the invention should only be limited 
by the Claims included below. 



1. An apparatus for smoothly playing a pre-determined 
sequence of songs transmitted from a server over the Inter- 
net, the apparatus comprising a processor, a first memory 
that stores at least one program used by said processor to 
control the playing of the sequence of songs, and a second 
memory which is available to said at least one program for 
operations, 

wherein said at least one program causes said processor at 
least to: 

as soon as a song starts to play, start to download, 
consecutively, a first small portion of each of a number 
of songs which are, in the pre-determined sequence, 
subsequent to the song in playing, said downloaded 
small portions being pre-cached in a buffer which is an 
area in said second memory; 

as soon as the user skips to a target song whose first small 
portion has been pre-cached, start to play the first small 
portion of said target song; and 

at the same time start to download the rest of said target 
song so that as soon as the playing of the first small 
portion of said target song ends, start to play the rest of 
said target song which is being downloaded from the 
server over the Internet. 



2. The apparatus of claim 1, wherein said first small 
portion is approximately the data required for playing the 
first ten seconds. 

3. The apparatus of claim 1, wherein said number is five. 

4. The apparatus of claim 1, wherein said number of songs 
is all songs subsequent to the song in playing. 

5. The apparatus of claim 1, wherein said buffer follows 
a first-in first-out algorithm and allows writing while read- 
ing. 

6. A method for smoothly playing a pre-determined 
sequence of songs transmitted from a remote server to a 
local device over the Internet, comprising the steps of: 

(a) as soon as a song starts to play, downloading, con- 
secutively, a first small portion of each of a number of 
songs which are, in the pre-determined sequence, sub- 
sequent to said song in playing; and 

(b) pre-caching said downloaded small portions in a 
buffer which is an area of said local device's memory. 

7. The method of claim 6, further comprising the steps of: 

(c) as soon as the user skips from a song in playing to a 
target song, checking whether a file for said target song 
exists in said buffer, wherein if the check result is yes, 
continuing on step (d); 

(d) playing the first small portion of said target song; and 

(e) as soon as step (d) starts, downloading the rest of said 
target song; 

(f) as soon as step (d) starts, deleting any pre-cached song 
prior to said target song in said pre-determined 
sequence; and 

(g) playing the rest of said target song which is being 
downloaded from the server over the Internet. 

8. The method of claim 7, further comprising the step of: 

(h) as soon as step (d) starts, continuing on step (a), 
wherein if one or more songs subsequent to said target 
song are already pre-cached, skipping said one or more 
songs and downloading the subsequent ones, execu- 
tively, to make up said number. 

9. The method of claim 8, further comprising the steps of: 

(i) if no skip command is given by the user while said 
target song is playing, as soon as the playing of said 
target song ends, playing the next song immediately 
subsequent to said target song; and 

(j) if a skip command is given by the user while said target 
song is playing, continuing on step (c). 

10. The method of claim 7, wherein if the check result of 
step (c) is no, further comprising the steps of: 

(k) sending request to stop transmitting of said song in 
playing and start transmitting said target song; 

(1), at the same time with step (k), deleting the pre-cached 
portion for any song which is prior to said target song 
in the pre-determined sequence of songs; 

(m) downloading said target song; 

(n) playing said target song while being downloaded as 
soon as said buffer allows so; and 

(o) at the same time with step (n), continuing on step (a). 
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11. The method of claim 10, subsequent to step (n), further 
comprising the steps of: 

(p) if another skip command is given by the user while 
said target song is playing, continuing on step (c); and 

(q) if no skip command is given by the user while said 
target song is playing, as soon as the playing of said 
target song ends, playing the first small portion of the 
next song subsequent to said target song; 

(r) at the same time with step (q), downloading the rest of 
said target song; 

(s) at the same time with step (q), continuing on step (a), 
wherein if one or more songs subsequent to said next 
song are already pre- cached, skipping said one or more 
songs and downloading the subsequent ones, execu- 
tively, to make up said to number; and 

(t) subsequent to step (q), playing the rest of the next song 
which is being download from the server over the 
Internet 

12. The method of claim 6, wherein said first small 
portion is approximately the data required for playing the 
first ten seconds. 

13. The method of claim 6, wherein said number is five. 

14. The method of claim 6, wherein said number of songs 
is all songs subsequent to the song in playing. 

15. The method of claim 6, wherein said buffer follows a 
first-in first-out algorithm and allows writing while reading. 

16. A program storage medium readable by a computer, 
tangibly embodying a program of instructions executable by 
the computer to perform a method for smoothly playing a 
pre-determined sequence of songs transmitted from a remote 
server to a local device over the Internet, comprising the 
steps of: 

(a) as soon as a song starts to play, downloading, con- 
secutively, a first small portion of each of a number of 
songs which are, in the pre-determined sequence, sub- 
sequent to said song in playing; and 

(b) pre-caching said downloaded small portions in a 
buffer which is an area of said local device's memory. 

17. The program storage medium of claim 16, further 
comprising the steps of: 

(c) as soon as the user skips from a song in playing to a 
target song, checking whether a file for said target song 
exists in said buffer, wherein if the check result is yes, 
continuing on step (d); 

(d) playing the first small portion of said target song; and 

(e) as soon as step (d) starts, downloading the rest of said 
target song; 

(f) as soon as step (d) starts, deleting any pre-cached song 
prior to said target song in said pre-determined 
sequence; and 

(g) playing the rest of said target song which is being 
downloaded from the server over the Internet. 

18. The program storage medium of claim 17, further 
comprising the step of: 

(h) as soon as step (d) starts, continuing on step (a), 
wherein if one or more songs subsequent to said target 



song are already pre-cached, skipping said one or more 
songs and downloading the subsequent ones, execu- 
tively, to make up said number. 

19. The program storage medium of claim 18, further 
comprising the steps of: 

(i) if no skip command is given by the user while said 
target song is playing, as soon as the playing of said 
target song ends, playing the next song immediately 
subsequent to said target song; and 

(j) if a skip command is given by the user while said target 
song is playing, continuing on step (c). 

20. The program storage medium of claim 17, wherein if 
the check result of step (c) is no, further comprising the steps 
of: 

(k) sending request to stop transmitting of said song in 
playing and start transmitting said target song; 

(1), at the same time with step (k), deleting the pre-cached 
portion for any song which is prior to said target song 
in the pre-determined sequence of songs; 

(m) downloading said target song; 

(n) playing said target song while being downloaded as 
soon as said buffer allows so; and 

(o) at the same time with step (n), continuing on step (a). 

21. The program storage medium of claim 20, subsequent 
to step (n), further comprising the steps of: 

(p) if another skip command is given by the user while 
said target song is playing, continuing on step (c); and 

(q) if no skip command is given by the user while said 
target song is playing, as soon as the playing of said 
target song ends, playing the first small portion of the 
next song subsequent to said target song; 

(r) at the same time with step (q), downloading the rest of 
said target song; 

(s) at the same time with step (q), continuing on step (a), 
wherein if one or more songs subsequent to said next 
song are already pre-cached, skipping said one or more 
songs and downloading the subsequent ones, execu- 
tively, to make up said number; and 

(t) subsequent to step (q), playing the rest of the next song 
which is being download from the server over the 
Internet 

22. The program storage medium of claim 16, wherein 
said first small portion is approximately the data required for 
playing the first ten seconds. 

23. The program storage medium of claim 16, wherein 
said number is five. 

24. The program storage medium of claim 16, wherein 
said number of songs is all songs subsequent to the song in 
playing. 

25. The program storage medium of claim 16, wherein 
said buffer follows a first-in first-out algorithm and allows 
writing while reading. 



